this is a bit inefficient from an IO perspective, since _get_zarr_version does IO against metadata documents, and cls.open will do more IO against the same documents.

I think it's more efficient to:

• avoid recursion here
• instead of using a function that checks if objects exist (_get_zarr_version), use a function that returns an existing array or group directly. This is a more efficient use of IO. I think get_node, or one of the functions it relies on, could be used here.

Ah, good point about the IO operations. I naively assumed a exists() operation would be much cheaper than get(), but I guess on remote stores that's not the case. I've refactored to avoid recursion, and minimise IO. When working out whether a group is v2/v3 there's now two less IO operations, which is a nice win.

instead of using a function that checks if objects exist (_get_zarr_version), use a function that returns an existing array or group directly. This is a more efficient use of IO. I think get_node, or one of the functions it relies on, could be used here.

I'm not sure what you meant by this?

sorry if I wasn't clear. one of the outcomes of open is to return an existing group (and if there's an existing array, or an existing group with the wrong zarr format, we should error). So instead of using a function that just infers the zarr_format of an existing array / group, it's likely simpler to simply try and open an array / group, and then handle the result of that operation.

This is called further down the stack than the "high level" functions to open groups, so I don't think that would work? e.g., for zarr.open_group() the call stack is:

zarr.open_group()
zarr.api.asynchronous.open_group()
AsyncGroup.open()